In a traditional public key infrastructure, a trusted central authority issues certificates that provide participants with public/private cryptographic key pairs, and similarly the trusted central authority provides a list of compromised keys through the issuing of a revocation list. A number of methods, systems and processes are known for providing a revocation service, for example as taught in U.S. Pat. No. 9,118,486 and U.S. Pat. No. 7,543,140.
Distributed ledgers provided in peer-to-peer systems, such as the blockchain used in the Bitcoin cryptocurrency system, rely on public/private cryptographic key pairs for the signing of transactions that transfer credits of commercial value between entities. In such systems, participants generate and manage their own public/private key pairs rather than relying on a third-party trusted central authority.
A problem in systems such as Bitcoin is that when a private key becomes compromised, for example by being made public, any entity knowing the private key can create and sign transfer messages to transfer credits allocated to the public key associated with the compromised private key, hence taking ownership of the credits. Some entities even run computer programs that constantly monitor compromised private keys and their associated public keys on the Bitcoin system, and transfer credits out as soon as they are credited to the compromised public key.
Another problem in systems such as Bitcoin is that a public key associated with the private key 0 is a valid key for transferring credits to, but the credits can never be redeemed. Due to the structure of the asymmetric key system used (the Elliptic Curve Digital Signature Algorithm, or ECDSA), credit transfer messages cannot be signed with the private key 0. As a result, the public key associated with the private key 0 currently holds a significant level of unredeemable credits. Computer programming errors can result in the accidental generation of the private key 0 rather than a valid private key, and subsequent accidental crediting of the public key associated with the private key 0, resulting in a permanent loss of the credits.
Both the aforementioned problems could be overcome by the existing prior art of key revocation lists produced and published by a trusted central authority in order to determine if a given cryptographic key has been compromised, and hence revoked. However, in distributed peer-to-peer systems, by definition there cannot be a trusted central authority to turn to, and so the prior art is of no use.
It is the intention of the present invention to address the shortcomings of the prior art, that is, the problem of reliably revoking a public/private cryptographic key pair used in a distributed peer-to-peer system in the absence of a trusted central authority.